SRE面试常见错误：混淆SLI与SLO定义导致挂科
一句话总结
SLI是仪表盘上的指针读数，SLO是那个读数必须落进的区间，SLA是读数越界后你要掏的钱。大多数候选人在面试里把这三者搅成一团浆糊，不是因为不懂技术，而是因为他们从来没在凌晨三点被pager duty叫醒过。面试官要的不是你背得出定义，而是你在压力之下能否快速区分"我们测什么"和"我们承诺什么"——这个区分失误，直接触发hiring committee的否决票。
适合谁看
这篇文章写给正在准备Google、Meta、Netflix、Amazon等一线科技公司SRE岗位面试的人，尤其是从开发岗转SRE、或者从中小厂跳大厂的候选人。如果你把SRE理解为"会写代码的运维"，或者认为SRE面试就是考Kubernetes命令和Prometheus配置，你需要重新校准。这里也适合已经面过一轮但收到"需要加强系统设计 fundamentals"反馈的人——那个feedback的真正含义通常是"你连SLI和SLO都讲不清楚，却敢聊可靠性工程"。
另一个群体是负责SRE hiring loop的面试官和hiring manager。如果你发现候选人能背出Google SRE Book的章节号却通不过system design，问题可能出在面试问题的设计上，而非候选人的准备不足。最后，这篇文章也适合那些拿到offer后在negotiate package的人——SRE的薪资结构与SWE存在微妙差异，RSU占比和on-call津贴的谈判空间，往往在面试表现评级中就已经被锚定。
不是"会背定义"，而是"能在事故中做判断"
候选人走进面试间，面试官说"给我定义一下SLI"。大多数人开始复述："SLI是服务质量指标，SLO是目标……" 面试官点头，然后抛出一个跟进："好，你的电商平台的购物车服务，SLI是什么？"
错误版本立刻暴露。候选人会说"购物车的SLI是可用性99.99%"。这句话在hiring committee的debrief里会被标记为"fundamental misunderstanding"。可用性99.99%是SLO，不是SLI。SLI是"购物车API的成功请求比例"，是一个比值，是一个可以在Grafana上随时间波动的曲线。SLO是那个比值必须大于0.9999的约束条件。把两者混为一谈，意味着候选人在真实场景中会把"指标"和"目标"当成同一个东西，从而无法判断"当前系统是否健康"——因为健康不是数字本身，是数字与阈值的相对关系。
正确的回答需要展示三层结构。第一层，给出SLI的精确定义："购物车的SLI我选择'请求延迟'，具体是p99延迟，测量的是从API gateway收到请求到返回响应的时间间隔。" 第二层，说明SLO："这个SLI的SLO是p99 < 200ms，基于过去两个季度的季度业务高峰数据。" 第三层，最关键，是SLA的引入位置："如果连续两个监控周期p99超过200ms，我们触发pager；如果月度累计违规超过0.1%，触发SLA赔偿条款。" 这三层不是教科书知识，而是凌晨两点incident commander的实际工作流。
面试官在这个问题上的真正考察点，是候选人能否在压力下快速完成"测量-目标-后果"的链条。不是A，而是B：不是考察你是否知道SLI的全称，而是考察你在模糊定义下能否快速锚定一个可操作的监控方案。Google的SRE面试手册里，这个环节被称为"operationalizing reliability"，评分标准从"能定义"到"能设计监控系统"到"能在资源约束下做 trade-off"分为三档。大多数人停在第一档。
> 📖 延伸阅读：meta-e5-pm-tan-pan-dian-zi-you-xiang-mo-ban-jing-zheng-dui-shou
不是"指标越多越好"，而是"少即是多的勇气"
面试中一个经典的死亡陷阱是候选人试图展示全面性，一口气列出十几个SLI。"我们的SLI包括可用性、延迟、吞吐量、错误率、CPU利用率、内存使用率、磁盘I/O、网络延迟、连接数、队列深度……" 面试官会打断你。不是因为时间不够，而是因为这暴露了你在真实生产环境中从未被指标淹没过的天真。
Netflix的SRE团队在公开分享中提到过他们的"四个黄金信号"：延迟、流量、错误、饱和度。不是因为他们不知道其他指标的存在，而是因为经过无数次on-call rotation的教训，他们发现超过四个核心SLI的团队，SLO的遵守率反而下降。原因是心智带宽的分配——每个SLI都需要对应的on-call runbook、alerting rule、postmortem模板。指标膨胀直接导致操作疲劳，而操作疲劳是可靠性工程最大的敌人。
正确的做法是在面试中展示"战略性放弃"。一个高分回答的轮廓是这样的："我选择两个SLI。第一个是'添加商品到购物车的p99延迟'，第二个是'完成结账流程的成功率'。不选吞吐量，因为在我们的业务模型中，购物车服务的瓶颈从来不是QPS，而是第三方支付接口的异步回调延迟。如果我们监控吞吐量，会收到大量无法行动的警报。" 这段话的价值不在于技术深度，而在于展示了你理解"监控的目的是行动，不是信息收集"这个原则。
不是A，而是B：不是考察你对监控系统的熟悉程度，而是考察你在信息不完备时做减法的能力。面试官会进一步施压："如果CEO坚持要加一个'页面加载时间'的SLI，你怎么回应？" 错误版本是技术辩论："页面加载时间受客户端网络影响，不是服务端能控制的。" 正确版本是商业翻译："页面加载时间是一个用户体验指标，建议由前端团队作为独立SLI管理，与购物车服务的SLO解耦。如果我们强行纳入，会稀释现有on-call团队对核心交易路径的关注度。" 这个回答把技术决策翻译成了组织决策，正是senior SRE的核心能力。
不是"SLO越严越好"，而是"违约成本的可承受性"
候选人常常误以为SLO必须追求极致。面试中一个典型错误是："我们的SLO是99.999%可用性，也就是每年 downtime 不超过5分钟。" 面试官会追问："你们怎么做到的？" 如果候选人开始描述多活架构、自动故障转移、混沌工程，面试官会在"practicality"维度打低分——因为这个问题真正的陷阱在于，那个SLO本身可能就是不合理的。
不是A，而是B：不是考察你能否设计出高可用架构，而是考察你能否识别"过度设计"的商业荒谬性。一个99.999%的SLO，如果对应的业务是内部员工使用的费用报销系统，其engineering cost可能远超潜在的SLA赔偿。正确的分析框架是：SLO的严格程度必须与"违约的业务后果"匹配，而不是与"技术能实现的上限"匹配。
具体场景：一个候选人在Meta的SRE面试中被问到"News Feed的SLO应该是什么"。高分回答的结构是：首先，区分不同用户群体的敏感度——付费广告主的API可用性SLO必须高于普通用户的浏览体验SLO；其次，量化违约成本——广告主API每不可用1小时，直接收入损失是多少万美元，这个数字决定了你愿意投入多少engineering resource；最后，给出可操作的escalation路径——当SLO逼近违规阈值时，是优先回滚版本还是优先扩容，取决于当前incident的根因判断。
这个回答的精妙之处在于，它把SLO从一个技术指标转化为了商业合约的条款。面试官在debrief中的原话通常是："这个候选人理解SLO是谈判结果，不是技术宣言。" 这正是从senior到staff级别的分水岭。
> 📖 延伸阅读：Netflix数据科学家面试怎么准备
面试流程拆解：每一轮都在筛什么
Google的SRE面试通常是5-6轮，分布在两天。每一轮的考察重点和时间分配，直接反映了他们对"混淆SLI/SLO"这类错误的零容忍态度。
第一轮，45分钟，Phone Screen。不是考coding，而是考"能否说清楚话"。面试官通常是一个senior SRE，问题形式是"描述你过去负责的一个服务，你的SLI和SLO是什么"。这里不合格的候选人，在15分钟内就会暴露出定义混淆。合格的候选人会用2分钟讲清背景，10分钟深入一个具体SLI的选取理由，5分钟讨论SLO设定的依据，最后5分钟留出给面试官提问。
第二轮，45分钟，Coding。SRE的coding轮与SWE不同，不是算法题，而是操作型编程——比如写一个脚本分析日志，或者实现一个简化版的负载均衡器。这里的关键不是复杂度，而是code的可维护性和错误处理。一个常见的follow-up是："如果你的脚本监控的SLI超过SLO，你怎么alert？" 错误版本是"打印到stdout"或者"发邮件"。正确版本是"写入一个structured log，由下游的alerting system消费，同时支持dry-run模式避免误报"。
第三轮，45分钟，System Design。这是SLI/SLO混淆最容易致命的地方。设计一个分布式系统后，面试官一定会问"你的SLI是什么"。不是A，而是B：不是考察你能否设计高可用架构，而是考察你在设计完成之前是否已经把reliability作为一等公民纳入架构。高分候选人会在白板的第一象限画出SLI/SLO表格，与架构图并行迭代，而不是作为事后补充。
第四轮，45分钟，Behavioral/Leadership。Google叫Googliness，Meta叫Leadership Principles。这里的陷阱是"描述一次你为一个服务设定SLO的经历"。候选人常犯的错误是描述一个完美成功的故事。高分回答的结构是：我们最初设定了一个错误的SLO（具体是什么），导致了什么后果（用户投诉或资源浪费），我们如何识别这个错误（数据或反馈），以及我们如何修正（具体的迭代过程）。展示失败和学习，比展示完美更可信。
第五轮，45分钟，Domain Expertise。可能是Unix internals、Networking、或者Security。这一轮与SLI/SLO的直接关联较弱，但面试官会观察你在技术细节上的严谨性——一个连TCP重传机制都讲不清楚的人，不可能设计出可靠的延迟SLI。
第六轮，30-45分钟，Hiring Manager Round。这不是形式，而是hiring manager在评估"我是否愿意让这个人在我的on-call rotation里"。问题通常更开放："如果我们把某个服务的SLO从99.9%提升到99.99%，你需要什么资源？" 错误版本是直接报价："需要10台服务器"。正确版本是先问上下文："这个SLO提升的商业驱动是什么？当前的主要违约根因是什么？提升后的违约成本是否justify投入？" 这展示了系统思考能力。
不是"回答正确"，而是"让面试官想跟你做同事"
一个insider场景：Google的hiring committee在review一个SRE候选人时，面试反馈表上有一个隐藏维度叫"would I want to be on-call with this person"。不是字面意思，而是评估候选人在压力下的协作模式。SLI/SLO问题的回答质量，是这个维度的重要输入。
具体对话记录（基于公开debrief pattern重构）：
面试官A："他定义SLI的时候说'响应时间'，但没有说清是平均还是分位。我追问之后，他说'都可以'。这说明他没有理解p99和mean在SLO上下文中的本质区别——mean会被outlier平均掉，不适合作为用户体验的代理指标。"
面试官B："我在system design里故意没有提醒他SLO，看他是否会主动提出。他在20分钟后才想起来，而且只是附在架构图旁边说了一句'这里要监控'。没有讨论SLO的具体数值，没有error budget的概念，没有和release policy的关联。"
Hiring Manager："综合反馈是'no hire'。核心问题是reliability engineering fundamentals薄弱。建议6个月后重新面试，重点准备SLI/SLO/SLA的区分和实操。"
这个候选人后来复盘时意识到，他在准备阶段花了80%时间在Kubernetes和Terraform上，只花了10%时间在SRE Book的第二章。这个比例倒置是致命的。
不是A，而是B：面试准备不是技术栈的堆砌，而是对面试官评估维度的精准映射。另一个高分候选人的经历：她在system design轮主动在白板上画了一个"SLI/SLO/S error budget"的三层框架，面试官的眼睛"亮了一下"——这是面试官笔记中明确记录的细节。后来她得知，那个面试官正是Google SRE Book中error budget章节的贡献者之一。
准备清单
- 精读Google SRE Book第2章（SLI）和第3章（SLO），不是读一遍，而是能用自己的话复述其中的case study，特别是Borgmon的监控设计哲学。
- 准备三个自己经历过的具体场景，分别对应"SLI选取"、"SLO设定"和"error budget耗尽后的决策"。每个场景要能讲出当时的trade-off和事后验证。
- 系统性拆解面试结构（PM面试手册里有完整的SRE实战复盘可以参考），特别是system design轮中reliability维度的嵌入时机和表达方式。
- 练习用一句话区分SLI/SLO/SLA，要求不使用任何缩写全称，只用业务语言。例如："我们测量购物车页面多久能打开（SLI），我们承诺这个时间在两秒内（SLO），如果超过三秒我们赔钱（SLA）。"
- 研究目标公司的公开故障报告和postmortem，分析其中提到的SLO违规情况和补救措施。Netflix的技术博客、Google Cloud status page、AWS postmortem都是好材料。
- 找一个senior SRE做mock interview，重点不是技术正确性，而是时间分配——你是否能在45分钟内自然地把SLI/SLO discussion嵌入system design，而不是被面试官提醒后才补上。
- 准备"反事实"问题：如果你的SLO设置错了，怎么发现？怎么修正？这个问题在senior级别的面试中出现频率超过60%。
常见错误
错误一：把SLO当作SLI的技术参数
BAD版本：面试官问"你的SLI是什么"，候选人回答"99.9%可用性"。这是直接把SLO的数值当成了SLI的名称。正确的区分是：SLI是"成功请求数/总请求数"这个比值，SLO是那个比值≥0.999的约束。
GOOD版本："我的SLI是'商品详情页API的成功率'，具体定义是HTTP 200响应数除以总请求数，排除4xx客户端错误。SLO是这个比值在任意24小时窗口内不低于0.999。SLA是基于月度数据，如果低于0.999，触发服务信用赔偿。"
错误二：在system design中把SLI/SLO作为事后补充
BAD版本：候选人花了35分钟画架构图，最后5分钟被面试官提醒"你的SLO是什么"，才匆忙补上"哦对，我们要监控延迟"。这暴露了reliability不是设计的一等公民。
GOOD版本：在架构图的第一版就包含一个"Reliability Layer"框，里面有具体的SLI表格、SLO数值、以及对应的monitoring和alerting设计。面试官追问时能展开讨论error budget的分配策略。
错误三：用"越多越好"回应SLI数量问题
BAD版本：当被问到"你会选几个SLI"时，回答"越多越好，全面监控"。这显示了缺乏生产环境的操作经验。
GOOD版本："我倾向于从用户旅程出发，选择2-4个核心SLI。对于电商购物车，我关注'添加成功'的延迟和'结账完成'的成功率。不单独监控库存查询的延迟，因为它是结账的从属步骤，其异常会反映在结账成功率的下降上。"
FAQ
Q1：我在中小厂没有SLO的文化，面试时怎么弥补这个gap？
你的经历不是劣势，是差异化的素材。关键在于展示"如果我来做，我会怎么做"，而不是"我们没做过所以我不会"。具体做法：选一个你维护过的服务，描述你手动收集过的reliability数据（哪怕是 uptime 的粗略估算），然后展示你如何将其formalize为SLI/SLO。例如："我维护的支付回调服务，过去半年我通过日志分析发现p99延迟在800ms左右，但业务方没有明确预期。如果我来设定SLO，我会先和业务方确认800ms是否可接受，还是我们需要投入资源优化到200ms。这个协商过程本身就是SLO的价值。" 面试官要看的不是你所在公司有没有SRE文化，而是你是否具备建立这种文化的思维模式。
Q2：SRE的薪资谈判有什么特别之处？
SRE的薪资结构与SWE类似，但存在两个关键差异。Base范围通常在$120K-$220K，与SWE基本持平。RSU占比往往更高，可达总包的40-50%，因为SRE岗位在部分公司被视为"retention critical"——培养一个熟悉核心系统reliability的SRE成本极高，公司愿意用更多RSU锁定。Bonus通常为base的15-20%，但senior以上可能有on-call bonus或incident response bonus，这部分在面试阶段就应该问清楚。谈判策略上，如果你展示了扎实的SLI/SLO功底，可以argue自己是"production-ready"的候选人，要求更高的initial equity grant。一个具体的锚定点：如果你的system design轮feedback是"strong hire"且明确提到reliability fundamentals solid，你的negotiation leverage会比同等SWE高出10-15%。
Q3：如果面试官自己把SLI和SLO说混了，我该纠正吗？
这是一个高风险的社交判断题。不是A，而是B：不是考察你的技术正确性，而是考察你的协作情商。具体策略：如果这是hiring manager或者明显senior的人，不要直接纠正。可以用提问的方式重新确认："我想确认一下我们讨论的框架，您提到的这个99.9%是指我们测量的指标目标，还是指标本身？" 这样既展示了你的精确性，又给了对方台阶。如果是peer interviewer，且氛围比较轻松，可以半开玩笑地说："我习惯上会把SLI和SLO分开，这样我们后面的讨论更清晰——您看这样可以吗？" 关键是不要让面试官感到被challenge，同时展示你的专业严谨。在hiring committee的debrief中，"courteous but precise"是一个高分标签。
（全文约4200字）
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。